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Field of the Invention 



The present invention generally relates to a video capture system and its methods, and 
more particularly relates to capturing compressed and uncompressed digital video data. 



Digital Video Broadcast (DVB) transmission standards have been developed in order to 
support the emergence of digital television. As illustrated in prior art Figure 1, the DVB signal is 
sent via an analog carrier and received by a tuner. The tuner receives the transmitted analog 
signal and provides an analog representation of the signal to a demodulator portion. The 
demodulator portion converts the analog signal into its digital format. The digital signal 
provided by the demodulator is in a compressed MPEG 2 format. The compressed MPEG 2 
format is referred to as a transport stream. The transport stream from the demodulator comprises 
a plurality of packets. Each of the transport stream packets comprises one synchronization byte, 
followed by one of 187 data bytes or 187 data bytes plus 16 extra bytes depending on the format. 
The resulting transmission stream packets have a total byte size of one of 188 bytes, or 204 
bytes. 

The data contained within each packet of the transmission stream can represent video 
data, audio data, system data, and other user data such as programming information. In other 
words, more than just video data is provided within the transmission stream. For example, user 
guides indicating channel selection information or stock market information could be included 
within a transmission stream packet. Because the transport stream data is contained in a 
compressed format, when video is being transmitted, there is not a one-to-one correspondence 
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between the actual bytes being transmitted in the transport stream and the pixels which the data 
represents. Because the data is compressed, one packet of transmission stream data can represent 
varying numbers of pixels in a video system. 

A transport demultiplexor receives the digital transport stream as illustrated in prior art 
5 Figure 1. The transport demultiplexor is capable of routing the individual components 

represented within the transport stream to the respective clients. In other words, audio data could 
be provided to an audio client while video data would be provided to a video client. For 
example, the transport demultiplexor can route data by providing address information to the PCI 
bridge of Figure 1. 

10 Also illustrated in the nrfor art of Figure 1 is a Peripheral Component Interconnect (PCI) 

Bus supporting conventional computer-type peripherals. Connected to the PCI Bus of Figure 1 
are a Memory, a centra^Trocessor Unit (CPU), and a Video Adapter. In order to support the 
reception and subsequent transmission of the transport stream to one of the system components, 
such as to the Memory or the Video Adapter, a Converter/PCI Bridge has been used. The 
15 converter potion is necessary in order to change the transport stream into data packets capable 
of being transmitted across a system bus, such as through the PCI bridge. Such a conversion 
would Require converting the 188-byte packet of the transport stream into 32-bit or 64-bit wide 
wonas of information and transporting the words to Memory or the Video Adapter across the PCI 
s. 

20 In order to pro/ide data to the video adapter of the prior art, it is necessary for separate 

printed circuit boards to be used to implement the transport stream converter and video adapter. 
Separate boards/allows a PCI interface to the video memory associated with the video adapter. 
Separate boara increase overall system costs. In addition to increasing overall system costs, the 
data strearn data requires approximately 5 Mbytes of PCI bandwidth, thereby limiting the 
25 bandwidth available to other system resources. In addition, when analog video is received and 
digitized (not illustrated),by the prior art system the PCI band data bandwidth is approximately 
25 Mbytes. 

Another proposed method for receiving DVB data was to use the side port of a video 
graphics adapter in order to receive the transport stream information. However, the video side 
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port is designed to only/^ceive uncompressed digital video instead of compressed MPEG 
X/ transport stream. A/format conversion chip is needed between the DVB demodulator output and 
video side portfcfconvert a transport stream into a compatible ITU-656 ancillary stream (digital 
video or dateTormat) like format. This will add cost to system implementation. Another problem 
5 is that the data in the transport stream is not fully compliant with ITU-656 data, (values such as 
00 and FF are not allowed in an ITU-656 stream but allowed in a transport stream. So this 
incrementation cannot work if the video side port is strictly designed for ITU-656 data streams. 

Therefore, a method and apparatus, which overcome the problems of the prior art, would 
be advantageous. 
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Brief Description of the Drawings 
Figure 1 illustrates, in block diagram form, a prior art system for receiving a transport 

stream; 

Figure 2 illustrates, in block diagram form, a system in accordance with the present 
15 invention; 

Figure 3 illustrates, in block diagram form, a detailed view of a portion of Figure 2; 
Figures 4 and 5 illustrate, in block diagram form, a detailed view of a portion of Figure 3; 
Figure 6 illustrates an active video area in a video frame. 

Figures 7 and 8 illustrate, in timing diagram form, timing signals associated with one type 
20 of digital video; 

Figure 9 illustrates, in timing diagram form, timing signal associated with a transport 

stream; 

Figure 10 illustrates, in block form, a memory associated with Figure 5; and 
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Figure 1 1 illustrates, in flow diagram form, a method in accordance with the present 
invention. 



Detailed Description of the Drawings 

A method and apparatus for receiving one of a compressed video stream and an 
uncompressed video streamas disclosed. The uncompressed video stream may be Zoom Video 
data or a digitized analog video signal. The compressed video stream may be an MPEG 
transport stream data/from a High Definition television (HDTV) broadcast. A Video Graphics 
Adapter is configjired to properly receive one of the two types of video data. The received data 
and control signals are monitored to provide a second set of control signals that are used by a 
packer, a window control, and an address generator. The packer packs data into a format which 
is compatible with the frame buffer memory. The window controller controls the amount of data 
writteij into frame buffer memory. The address generator generates proper frame buffer 
addresses for the data. The data is stored within a pre-defined area of graphics memory such as a 
frame buffer. The data can be transferred to system memory when a buffer is full. 

Figure 2 illustrates a system in/accordance with the present invention. A digital video 
broadcast (DVB) signal is receivecFby the tuner 210. The tuner 210 provides a representation of 
the received analog signal to th# demodulator 220. The demodulator 220 demodulates the signal 
to provide a digital TRANSPORT STREAM to one or both of the Transport Demultiplexer 240, 
and the Video Adapter 230. In accordance with the present invention, the Video Adapter 230 
receives the TRANSPORT STREAM and buffers it into a video memory, or frame buffer. Upon 
filling the frame buffer, the transport stream data is either further utilized by the Video Adapter 
230, or at least partially provided to system components, such as the central processing unit 
(CPU) 250, orine memory 260. A second data path receives an analog signal, such as would 
normally be/associated with television broadcasts, at tuner 211. The signal from tuner 21 1 is 
provided to a NTSC/PAL/SECAM demodulator 221 to provide a digital representation of the 
received analog signal. Not that the tuner 211 and demodulator 221 may be the same, or 
differ/nt, from the tuner 210 and demodulator 21 1. 
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Figure 3 illustrates the Video Adapter 230 in greater detail. In normal operation, the 
Video Adapter 23P'processes video and/or graphics information and provides a signal labeled 
VIDEO OUT/The VIDEO OUT signal is used to drive an image onto an external display device 
(not showri). In accordance with the present invention, the Video Adapter 230 includes a 
Capture Block 310 to receive a data stream, a graphics engine 320, a graphics memory^ 1, and 
a BCI interface 340. 

In operation, the a digjtel data stream, such as the TRANSPORT STREAM from the 
demodulator 220 o^Figure 2, is received at the capture block 310. Where the digital data stream 
is a TRANSPORT STREAM, the TRANSPORT STREAM comprises both data, and control 
information. /Generally, the TRANSPORT STREAM includes a plurality of packets. Each 
packet of transport stream information includes a synchronization byte followed by a 
predetermined number of data bytes. The data bytes can include routing information stored as 
header information, or as raw data as identified by the header information. When the data is 
transmitted as header information, it is in an uncompressed form that indicates the type of data 
tnat is to follow the header. A single header can be included in one or more packets. 

The Capture Bl6ck 310 receives the TRANSPORT STREAM information and provides 
the necessary data^nd control in order to store the compressed transport stream data within the 
Graphics Memory 330. The memory 330 is accessed over the bus 350. In a specific 
embodiment; the memory 330 is a frame buffer used by the Graphics Engine 320. The Memory 
330 is connected to the Capture Block 310 through the bus 350 which accommodates the 
necessary data, address, and control lines for accessing memory 330. The graphics memory 330 
is *dso connected to the graphics engine 320 and the PCI Interface 340 through the bus 350. 

In accordance/vith the present invention, the graphics Memory 330 can operate as a 
frame buffer for tjafei Graphics Engine 320, or as a buffer to store the TRANSPORT STREAM 
data. The PCLmterface 340 provides an interface between the internal bus 350 to an external 
PCI bus. Generally, the PCI Bus will be a system bus. It should be noted that while a PCI 
interface/340 has been shown, the present invention anticipates the use of other type bus 
interfaces. Therefore, the PCI interface 340 may be any bus type whether an industry standard or 
a proprietary interface. 
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Figure 4 illustrates t#e capture block 310 in greater detail. Specifically, the capture block 
310 is shown to receive/number of different types of video data. As indicated, 8-bit DVS 
(Digital Video Strea#i) video and ZOOM VIDEO is received. Generally, the 8-bit DVS and 
ZOOM VIDEO data are ITU-601 or ITU-656 related digital video streams. These streams are 
not compressed video streams. However, the HDTV transport stream received by the capture 
block 3 10/5 f Figure 4, as previously mentioned, is a compressed video stream, such as MPEG 2. 
While m& DVS, ZOOM and TRANSPORT STREAM are illustrated in Figure 4 separately, in 
operation, the signals will share inputs that can be multiplexed, or de-multiplexed as needed. For 
example, the data bits from each format can be received by a common set of pins 

A signal labeled VIDEO SELECT is used to indicate to the Capture Block 310, which 
type of video is to4>e received. By allowing for one of a plurality of types of digital video data to 
be received, greater flexibility is realized within the video graphics adapter (VGA). This reuse 
of common circuitry allows for an efficient implementation of the present invention. Yet another 
advantage of the system as illustrated in Figures 3 is that it reduces system costs over the prior 
art in that the PCI interface 340 already residing within the VGA is used to store transport 
iffered stream data. 



Figure 5 illustrates the capture block 310 in greater detail. Figure 5 will be discussed 
with reference to Figures 6-10, which illustrate specific embodiments of the present invention 
including various timing diagrams. 



20 In Figure 5, th^TRANSPORT STREAM, and any other type of digital video, such as 

ZOOM VIDEO, i^eceived by the Video-In Controller 510 of Figure 5. The TRANSPORT 

^^^STREAM inchraes the signals 501, which include a multi-bit data signal (DATA), a 
#(^y synchronization signal (SYNCH), a data valid signal (D VALID), and a clock signal (TCK). The 
ZOOM VIDEO data is illustrated as a bus. However, it should be noted, that the signals 501 can 

25 be mmtiplexed and/or de-multiplexed (not shown) to receive either ZOOM VIDEO or 
TRANSPORT STREAM data. 



The Video-IrpController 510 acts as a stream interface control to convert the received 
signal, whether ZOOM VIDEO or a TRANSPORT STREAM, into a Start of Field (SOF) signal, 
a Start of Active (SO A) signal, an End of Active (EOA) signal, a Data Active (D ACTIVE) 



signal, 
% J Fi 




a Video Data (VDATA) signal. For ZOOM video, these signals are represented in 
r es 6 and 7. 
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Figure 6 represents a frame of video 610. In a specific embodiment, the video is 
representative of ZOOM VIDECX The frame of video 610 has a Vertical Blanking Interval 
(VBI) which resides in the first few lines of video. The VBI information is not displayed, but 
can be used to provide data for other operations of functions. Following the VBI portion, 
VIDEO is provided. Within the VIDEO portion, an Active Video 620 is illustrated which 
represents a portiojafof the VIDEO to actually be displayed. At the beginning of each line of the 
frame 610, a Stan of Active (SOA) pulse is provided. At the end of each line of the frame 610, 
an End of Arrive video (EOA) signal is provided. At the beginning the first line of the frame 
610, the start of a new frame is indicated by a Start of Frame (SOF) indicator. Note that the SOA 
and EQA refers to the active video relative to the ZOOM VIDEO standard which is the entire 
VIDEO portion is considered active video relative to the transmitted data. The Active Video 620 
'the Active Video relative to the user. 

The Active Video 620 o/Tigure 6 indicates the portion of the received VIDEO to be 
displayed. One example of life Active Video 620 varying from the received VIDEO is when the 
received video is High Definition Television (HDTV), which has a different aspect ratio than 
standard television, isoo be displayed on a standard television. In this mode of operation, it is 
desirable to selectonly a portion of the HDTV frame for display on a standard television screen. 
In order to specify the desired Active Video 620, it is necessary to specify a Y OFFSET 
indicated where the first line of Active Video 620 begins, a X OFFSET indicating which pixel is 
the first pjxel of Active Video 620, a WIDTH indicating the number of pixels in a containing 
Active Nideo 620, and a HEIGHT indicating the number of lines containing the active Video. 
Note/that the X OFFSET, and Y OFFSET are illustrated to be relative to the first line and pixel 
of/he frame 610. However, in other embodiments, other reference locations can be indicated. 

/-N Figure 7 illustrates the signals associated with ZOOM VIDEO. The ZOOM VIDEO 

Cr signals receive^y the Video-In Controller 5 1 0 are substantially similar to the signals provided 
by the Video4n Controller 510, except that no D ACTIVE signal is received. Therefore, since 
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there i&Ao equivalent signal to DACTIVE in Zoom video, the DACTIVE signal from video-in 
coijtfcller 510 specified is asserted when the Video-In Controller 510 receives data. 

In operation, the WindpW Control 520 receives the SOF, SOA, and EOA signals from the 
Video-In Controller 510. In addition, the Window Controller 510 receives, and/or has access to 
values indicating the X/OFFSET, Y OFFSET, WIDTH, AND HEIGHT values associated with 
Figure 6. These varies can be provide in any number of manners, including inputs to the 
Window Controller 520, or by accessing register locations. From the received values and 
signals, the Window Control 520 generates a second set of control signals: Window control Start 
of Field (V/SOF); Window control End of Field (WEOF); Window control End of Line 
(WEOLO; Vertical Active (V ACTIVE); and Horizontal Active (HACTIVE). These signals are 
further described with reference to the table below, and the relationship of the signal WSOF, 
iOF, AND WEOL are illustrated in Figure 8. 




VIDEO-IN OPERATION FOR ZOOM VIDEO 



ESCRIPTION 



Pulse active whejaf at first pixel of Active Video. 
Pulse active atTast pixel of Active Video. 
Pulse active at end of each line of Active Video. 
Asserted when pixel count within Width. 
Assorted when line count is with in HEIGHT. 
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The signal W&OF (Window control Start of Field) provides an asserted pulse when the 
first pixel of the ^tive Video 620 is encountered. The first pixel location can be determined by 
comparing th/X OFFSET and Y OFFSET values to the current pixel and line numbers, which 
are maintained by the system. For example, in one implementation, the Y OFFSET represents 
the firsnine of Active Video 620, while the X OFFSET represents the first pixel of Active Video 
620/Within a line. This is represented in Figure 8, where the signal WSOF is active at the same 



8 



v 



10 



time as the^dock pulse labeled L. The clock pulse L represents the time at which the first pixel 
of the Active Video 640 is available. 

The signal WEOF provides an asserted pulse when the last pixel of the Active Video 620 
is encountered. The last pixej/focation can be determined by comparing the sum of the WIDTH 
and X OFFSET values to^me current pixel number, and comparing the sum of the HEIGHT and 
the Y OFFSET values/fo the line number. For example, in one implementation, the X OFFSET 
plus the WIDTH lpss one indicates the last bit of Active video 620 associated with a line. 
Likewise, Y OFFSET plus the HEIGHT less one indicates the last line of Active Video 620. 
Therefore, by monitoring these values, the WEOF signal can provide an asserted pulse when 
both the last line and pixel of an Active Video 620 region is encountered. This is illustrated in 
Figure/8, where the signal WEOF is active at a time in conjunction with the clock pulse labeled 
N. yfhe clock pulse N represents the time at which the last pixel of the Active Video 640ys 
/ailable. 




j The signal WEOJ^provides an asserted pulse when the last pixel of a line of Active 

15 Video 620 is encounj^red. The last pixel of a line can be determined by comparing the sum of 
the WIDTH and x OFFSET values to the current pixel number. For example, in one 
implementation, the X OFFSET plus the WIDTH minus one represents the last bit of a line of 
Active Video 620. This number can be compared to the current pixel number to determine 
whethep'the end of line has occurred. WEOL is represented in Figure 8, where the signal WEOL 
20 is active at a time in conjunction with the clock pulses labeled M and N. The clock pulses M and 
epresents the time at which the last pixel of a line of data is available. 

The signal H^CTIVE is asserted when the current pixel location is within the WIDTH 
^^.region. Note tti^a pixel does not have to be in the Active Video 620 in order for HACTIVE to 
be asserted^Znis allows for an embodiment whereby only the pixel number is monitored and 
25 comparejno the values associated with the WIDTH of the Active Video 620. Likewise, the 
V ACTIVE signal is asserted when the current line number is within the HEIGHT region 
iicated in Figure 6. 

xO) It will be undej^ood by one skilled in the art, that the exact time at which the Window 

' Controller 510 provides a given control signal can vary depending upon specific embodiments. 




For ex^ffiple, the WEOL signal can be asserted in conjunction with the last pixel, or after the last 
pjx£l. 

Referring to Eigure 5 5 the signals generated by the Window Controller 510 are used by 
the Packer(i5^^il^ / the Address Generator6^6^to provide data and address to the buffer. In one 



embodimenj^ihe Packer :640jeceives 8-bit bytes of data, and combines them to form larger data 
words labeled VIDEO DATA. For example, the VIDEO DATA signal can comprise 32, 64, or 
128 Jrfit words of video data. The width of VIDEO DATA can be fixed or programmable. The 
>ACTIVE, HACTIVE, and VACTIVE signals qualify the VDATA received by the Packer 640. 

For ZOOMyiDEO, DACTIVE is always asserted. Therefore, the Packer ( 640 uses the 
HACTIVE andYACTIVE data to qualify VDATA. For example, when both DACTIVE and 
VACTIVE afe asserted, the data value received on VDATA is within the ACTIVE VIDEO 620, 
and will/be included by the Packer 640 within the VIDEO DATA. If either of DACTIVE and 
VACTIVE are inactive, the data value received on VDATA is not within the ACTIVE VIDEO 
§20, and will be not included by the Packer 640as part of the VIDEO DATA. 

The described embodiment for receiving ZOOM VIDEO provides for an efficient means 
to receive only a desired'portion of video data, however, the data received needs be readily 
associated with a specific line and a pixel in order to determine where the ACTIVE VIDEO 
resides. In contrast, DVB data is compressed, and visibility as to the line and pixel locations is 
not readily available without decompression of the data first occurring. In specific embodiments, 
it is desiraole to perform such decompression by other parts of the system, or at least to store the 
compressed data in other parts of the system. Therefore, one embodiment of the present 
invemion further allows compressed data, such as DVB transport steam data, to be buffered 
w^nin the Graphics Memory 330 of Figure 3. 



Figure 9 illustrates a timing diagram representing signals associated with the 
TRANSPORT^TREAM of Figure 2. The TRANSPORT STREAM includes a signal labeled 
TCK, whic^provides one clock pulse to qualify each byte of data.. A synchronization (SYNCH) 



10 



signaHridicates the beginning of a new line or packet of information. In addition, a data valid 
signal (DVALID) indicates when the packet data being transmitted is valid. 




In response td the TRANSPORT STREAM, the Video-In Controller 5 10 drives the 
signals SOF, SQA, EOA, DACTIVE, AND VDATA. The manner in which these signals are 
generatedjs'difSgrsnl for a TRANSPORT STREAM than for the ZOOM VIDEO previously 
discussea. The table below indicates the operation of the Window Controller 510 for 
TRANSPORT STREAM reception. 
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VIDEO-IN 
SIGNAL 





OPERATION FOR RECEPTION OF A TRANSPORT STREAM 



DESCRIPTION 



Pulse active to indicatethe 7 first byte of a transport stream packet to 

be stored in buffer. 
Pulse active to in the first byte of a transport stream packet. 
Pulse active w indicate the last byte of a transport stream packet. 
Asserted to indicate invalid bytes as indicated by DVALID. 

Data from TRANSPORT STREAM. 



During reception of the^RANSPORT STREAM, the SOF signal provides an asserted 
pulse to indicate that the fij^t byte to be stored in the Graphics memory 330 is present. In one 
embodiment, the Video4n Controller 510 will use a counter to keep track of the number of lines 
and bytes of comprised data provided to the Window Controller 5 10.^ When the number of 
lines sent to the Window Controller 51 (Exceeds the number of lines available in the Graphics 
Memory 330/rhe SOF is pulsed again to indicate a new first byte to be stored in the graphics 
memory. 2ne SOF signal of Figure 9 illustrates two pulses. The first pulse corresponds to TCK 
1, whicWis associated with the first data byte to be stored in the Graphics memory 330. The 
second SOF pulse occurs on the first TCK after line N has been transmitted, where N is the total 
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number of lin^to be stored in the Graphics memory 330. Note that in Figure 9, the number of 
bytes in ajme of video memory is 88. Coincidentally, this is the same number of bytes that are 
in a DATA STREAM packet. In other embodiments, the line size is different than the packet 
si^e, such that a line of video memory will not necessarily contain an integer number of packets. 

Note that the Graphics Memory 330 can have one or more buffer locations. Where 
multiple buffer locatkms are present, it is possible to switch between buffers when one buffer is 
full, and continue/storing data without delay, or with minimal delay, in a second buffer. If only 
one frame buffer is available, and it becomes full, it will be necessary to write at least some of 
the Graphics Memory 330 contents to system memory, or lose data by writing over the stored 
values/By using a dual ported Graphics Memory 330, it would be possible to buffer data and 
trarpnit it to the system simultaneously. In another embodiment, a single ported memory can 
Jso do the job, by interleaving between read and write operations. 

The Vide^-In Controller 510 signal SOA indicates that the first byte of a TRANSPORT 
STREAM packet is being transported. The SOA signal can be qualified by the TRANSPORT 
STREAM'S SYNCH signal. There are three such SOA pulsed indicated in Figure 9. 

The EOA signal indicates that the last byte of a TRANSPORT STREAM packet is being 
transmitted, or has been transmitted. In one embodiment, the generation of the EOA signal is 
determined by utilizing a counter, state machine, or ALU to determine when the predetermined 
number of bytes have been transmitted. Because the signal can be corrupted, there may not be 
the predetermined number of clock signals before the next SYNCH pulse occurs. Therefore, in 
another embodiment, a clock independent of the TCK can be used to determine when to assert 
the EOA signal. Such a clock can be phase locked to the SYNCH signal to maintain an accurate 
indication of when EOA is to occur. 

(fy The signal DACTIVE indicates when the data presented to the Packer 640 is valid. As 
indicated/m Figure 9, the signal DACTIVE will generally mirror the signal DVALID of the 
TRANSPORT STREAM. 

The signal VDATA will generally be the TRANSPORT STREAM data bytes 
(DATA(7:0)). 
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The Window Control 520 receives the SOF, SOA, and EOA signals from the Video-In 
Controller 510 representing the'TRANSPORT STREAM. In addition, the Window Controller 
510 receives, and/or has a<<cess to, values indicating the X OFFSET, Y OFFSET, WIDTH, AND 
HEIGHT values assorted with Figure 6. For TRANSPORT STREAM reception, the X 
OFFSET AND Y/OFFSET will generally be zero, the width will be number of bytes in the 
TRANSPORT/STREAM, and the HEIGHT will indicate the number of lines to be stored in the 
Graphics Memory 330. From the received values and signals, the Window Control 510) 
generates the signals: Window control Start of Field (WSOF); Window control End of Field 
(WEOF); Window control End of Line (WEOL); Vertical Active (V ACTIVE); and Horizontal 
;tive (HACTIVE). These signals are further described with reference to the table below. 

WINDOW CONTROL OPERATION FOR TRANSPORT STREAM DATA 



SIGNAL 



s 16 



20 




ESCRIPTION 



VACTIVE 
ACTIVE 



ulse qualified to SYJ>fCH signal and counter 
Pulse qualified to EOA. 
Pulse qualified j£ SOF and EOA. 

Assertion qualified to SOA and EOA when pixel count within 
Width. 

Asserted when between SOA pulse and EOA pulse. 
Asserted when between SOF pulse and WEOF. 



The signal WEOL provides an asserted pulse when the last byte of a TRANSPORT 
25 STREAM packet is encountered. Generally, WEOL signal will be based on the EOA signal. 

The sigpdl WSOF signal provides an asserted pulse to indicate the first byte to be stored 
within a bu^er of the Graphics Memory 330 buffer. For a specific embodiment, where the 
Video-iyController 5 1 0 monitors and maintains the number of lines being written, the WSOF 
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signal for^ TRANSPORT STREAM will be analogous to the SOF signal generated by the 
Vidp<5-In Controller. 

The signal WS0F signal provides an asserted pulse to indicate the last byte to be stored 
in the current buffer location of the Graphics Memory 330. The Window Controller 510^ 
generates the.WSOF signal by comparing the number of EOA signal received since SOF was 
active, amfcomparing this number to the provided HEIGHT value. By setting the Y OFFSET to 
zero, and the HEIGHT value to the number of lines in the Graphics Memory 330, it is possible 
foj^me Window Controlle^51^to generate the correct WEOF pulse without additional hardware. 

^ The isigilal HACTIVE is asserted when the current byte location is within the WIDTH 
region which is set to the number of bytes in a packet (188 bytes). 6. 

The sigrfal VACTIVE is asserted when the current data being received is to be stored be 
stored in die current line of the buffer. 

The Packer 640^>rovides a signal labeled ADDR GEN REQ, which indicates when a line 
of data is/eady to be stored in the Graphics Memory 330. The Graphics Memory 330 address 
and cofnrol information, is provided to the Graphics Memory 330 by the Address Generator 630 
wphi ADDR GEN REQ is active. 

With TRANSPORT STREAM data, it is possible for invalid data to be received. In order 
to provide visibility to other system portions as to when the stored TRANSPORT STREAM data 
is valid, a VALID byte location can be included as part of the buffer. Figure 10 illustrates one 
such VALID byte. By storing a unique value in this byte location, subsequent systems can be 
notified of the invalid data. In another embodiment, specific values can be stored to indicate 
those times when invalid data is received. In yet another embodiment, the entire line could be 
flushed, thereby only permitting valid lines of data to be stored. For types of uncompressed 
video where the valid byte is not needed, normal video data can be stored at the VALID location. 

An error sigfial can also be incorporated into the transport stream capture. When an error 
signal is received, a specific code can be generated and written with the data stream. Subsequent 
systems can^e notified that an error occurred by monitoring the data and react accordingly. 
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In this rnafiner, compressed and uncompress data can be stored in the frame buffer 
represented/by Graphics Memory 330. Once an entire frame of data is stored in the Graphics 
Memonf 330 the data can be written to system memory, or it can be decompressed by the 
Gnomics Engine 320. 

By Ijafrng the Video-In Controller 510 generate the SOF, SOA, EOA, D ACTIVE, and 
VDAT^in the manner indicated, it is possible to use much of the same hardware to implement a 
storage apparatus for both compressed and uncompressed video. 

Figure 1 1 illustrates a method in accordance with the present invention. Generally, the 
method of Figured 1 has been discussed with respect to the specific system herein. At step 1101, 
a determination is made whether a first or second type of video data is to be received. 
SpecificaHy, the first type of data represents TRANSPORT STREAM data as indicated in step 
1 102yThe second type of data represents a digital video stream different from a TRANSPORT 
STREAM, such as the ZOOM VIDEO signal discussed herein, as indicated at step 1 103 

At steps^ 102 and 1 103 the system is configured for either a TRANSPORT STREAM or 
a different digital video stream respectively. As discussed with respect to TRANSPORT 
STREAM and ZOOM Video herein, these configurations indicate how a video controller will 
gen^ttes its output signals. 

At step [ 104, a secondary set of control signals is generated from the received data 
stream. JThis corresponds to the Video-In Controller 510 generating signals SOF, SOA, EOA, 
DATIVE, AND VDATA, as discussed herein. 

At step 1 10^/at least a portion of the data stream is stored. Step 1 105 corresponds to the 
Window ConjFdUer 5TOn 9 Packer ^4b\ and Address Generator 530 working together as a data 
storage cpraroller to store words of data in a buffer associated with Graphics Memory 330. 
The^words of data will contain at least a portion of the data received by the Video-In 
Controller 510 in the manner discussed herein. 



At step 1 lOf^the information stored in the Graphics Memory 330 is written to a system 



At step l lUpf tne lnlormation stoi 
bus via the Pprfnterface 340 of figure 3 . 
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The present inventioniias been described with reference to specific embodiment. One of 
ordinary skill in the art will recognize that other embodiment may exist. For example, the data 
storage described h^r^in has be^escribed with reference to using SOF/EOF/SOA/EOA video 
fields to store transport stream data. In a similar manner, fields such as Start of VBI and End of 
VBI could be used to indicate when to store the transport stream data. Such an implementation 
would require the Window Controller 520 to provide indicators when VBI data is active and 
shoujd be stored. By indicating the VBI data had the same number of lines of the buffer 
associated with the Graphics Memory 330, the transport stream data can be stored. 



10 x 
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Anothejvvariation would allow the transport stream data to be stored in the buffer in a 
compress^form only when it is of a desired type of data. For example, the headers of the 
transppn stream can be monitor to allow only a specific type of data, such as video or audio, to 
be/buffered. 
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It should be further understoodJhat specific functions and steps described may actually 
be implemented in hardware and/oi^m software. For example, the signal generation performed 
by the Window Controller 520 c^n be performed by a hardware engine, firmware, such as in 
microcode, executed on the processing engine, or it may even be performed fully in software. In 
general, such functions can^oe performed in a processing module that may be a single processing 
device or a plurality of processing devices. Such a processing device may be a microprocessor, 
microcontroller, digital signal processor, microcomputer, portion of the central processing unit, 
state machine, logic circuitry, and/or any device that manipulates signals (e.g., analog or digital) 
based on operational instructions. The memory may be a single memory device or a plurality of 
memory devices. Such a memory device may be a read-only memory, random access memory, 
floppy disk'memory, magnetic tape memory, erasable memory, portion of system memory, 
and/or apy device that stores operational instructions in a digital format. Note that when the 
processing module implements one or more of its functions via a state machine or logic circuitry, 
the Memory storing the corresponding operational instructions is embedded within the circuitry 
comprising the state machine and/or logic circuitry. 

The specific embodiments of the present invention disclosed herein are advantageous in 
that transport stream data can be buffered in a portion of memory normally used by the Video 
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graphics adapter. Furthermore, the amount of overhead needed to store the transport stream data 
is minimal because the^system hardware/firmware/software is largely in place to handle the data. 
This is an advantage over other prior art embodiments which had dedicated hardware to merely 
convert transport stream data into a useful format before be received by a VGA controller. By 
allowing / transport stream data to be received directly by the VGA controller, cost savings and 
efficieitoes are gained. In addition, variations of the specific embodiments are anticipated. For 
example, the uncompressed video may be digitized NTSC/P AL/SECAM signals as well. 
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